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^ ABSTRACT 

A data  flow  machine  achieves  high  performance  by  the  concurrent 
execution  of  machine  code  consisting  of  data  flow  graphs  which  explicitly  represent 
the  data  dependencies  among  program  instructions.  This  thesis  presents  the 
operational  semantics  of  ADFL,  an  applicative  data  flow  language  with  an  iteration 

construct  resembling  tail  recursion  and  an  error-handling  scheme  appropriate  to  the 
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concurrency  of  data  flow.  The  operational  senyyiticsj^)  • f)  of  ADFL  are  expressed 
by  a two  step  process.  The  translation  algoritfim^J^  maps  an  ADFL  expression  into  its 
graph  implementation,  and  the  semantic  function  maps  the  graph  into  its  semantic 
characterization.  Data  flow  graphs  are  specified  by  use  of  a graph  assembly  language, 
and  the  semantics  of  these  graphs  are  derived  by  use  of  Kahn's  fixpoint  theory  of 
communicating  processes. 
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1.  Introduction 

Recently  many  novel  computer  architectures  which  achieve  high 
performance  through  the  use  of  concurrency  have  been  proposed.  Most  of  these 
designs  are  simple  variations  of  the  von  Neumann  model  of  computation  where  a 
sequential  process  manipulates  a memory.  The  effective  utilization  of  these  machines 
makes  special  demands  on  programmers  and  their  programming  languages,  such  as  the 
structuring  of  data  into  vectors  or  the  partitioning  of  programs  into  concurrent 
processes.  In  comparison,  the  data  flow  model  of  computation  demands  only  that  the 
principles  of  structured  programming  be  followed.  In  this  thesis  we  define  a data  flow 
programming  language  and  formally  specify  its  operational  semantics. 

In  a data  flow  machine,  an  operation  (instruction)  is  performed  as  soon  as 
its  operands  have  been  computed.  Data  flow  machines  accept  as  their  machine 
language  an  explicit  representation  of  the  data  dependencies  of  program  operations. 
Conventional  computer  languages  designed  to  facilitate  structured  programming  are 
easily  translated  into  data  flow  machine  code. 

1.1  The  Data  Flow  Model  of  Computation 

A data  flow  program  is  represented  by  a directed  data  (low  graph  whose 
nodes  are  called  operators.  The  role  of  operators  in  a data  flow  machine  is  similar  to 
the  role  instructions  in  a von  Neumann  machine.  The  execution  of  an  instruction 
corresponds  to  the  firing  of  an  operator.  Each  operator  has  several  labeled  input  and 
output  ports.  Whenever  an  operator  fires,  it  absorbs  values  at  its  input  ports  and 
produces  values  at  its  output  ports.  Operators  have  firing  rules  which  determine  when 
they  are  enabled  for  firing.  These  firing  rules  are  based  on  the  presence  or  absence 
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of  values  on  the  operator's  ports.  Most  operators  are  enabled  whenever  Input  values 
are  present  on  all  input  ports. 

When  operators  are  joined  to  form  data  flow  graphs,  the  links  of  the  graph 
are  directed  from  operator  output  ports  to  operator  input  ports.  A link  transports  the 
results  produced  at  an  operator  output  port  to  an  operator  input  port.  Thus,  links  form 
the  pathways  upon  which  data  flows  as  values  are  absorbed  and  produced  by  the 
firing  of  operators  during  the  execution  of  a graph.  Unlinked  operator  ports  within  a 
graph  are  the  ports  of  the  graph  itself.  Graphs,  like  operators,  absorb  values  at  Input 
ports  and  produce  values  at  output  ports. 

The  data  flow  graph  for  computing  the  distance  function: 
z = sqrt((x1 -x2)2  + (y1-y2)2) 

is  illustrated  in  Figure  1.1.  The  solid  black  dot  in  the  figure  represents  the  copy 
operator  which  is  used  to  distribute  the  results  of  one  output  port  to  several  input 
ports.  Note  how  this  graph  represents  operation  dependencies  and  independencies 
and,  consequently,  the  concurrency  obtainable  during  the  computation  of  the  distance 
function. 

1 .2  Research  in  Data  Flow  Computation 

There  are  two  prerequisites  to  the  practical  use  of  data  flow  computation: 
( 1 ),  a machine  which  executes  data  flow  graphs;  and  (2),  a programming  language 
which  can  be  translated  into  data  flow  graphs.  Preliminary  data  flow  machine  designs 
have  been  made  by  Dennis  and  Misunas  [9]  and  Arvind  and  Gostelow  [3].  Within  these 
machines,  a data  flow  graph  is  distributed  over  a network  of  processing  elements. 
These  elements  operate  concurrently,  constrained  only  by  the  operational 
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dependencies  of  the  graph.  Thus,  a very  efficient  utilization  of  the  machine's 
resources  appears  possible. 

Data  flow  programming  languages  resemble  conventional  languages 
restricted  to  those  features  whose  ease  of  translation  does  not  depend  on  the  state 
of  a computation  being  a single,  easily  manipulated  entity.  Because  the  "state"  of  a 
data  flow  graph  is  distributed  for  concurrency,  goto' s,  expressions  with  side  effects, 
and  multiple  assignments  to  the  same  variable  are  difficult  to  represent.  Since  these 
"features"  are  generally  avoided  in  structured  programming,  their  absence  from  data 
flow  languages  is  little  reason  for  lamentation. 

The  "First  Version  of  a Data  Flow  Language"  by  Dennis  [7]  was  a 
rudimentary  ALGOL-like  language.  Most  data  flow  languages  have  been  based  on  the 
principle  of  single  assignment : Variables  could  be  assigned  only  one  value  during  a 
program's  execution.  The  languages  of  Weng[19]  and  Arvind,  Gostelow,  and 
Plouffe  [5],  in  addition  to  having  the  expressive  power  of  ALGOL,  facilitate  the 
programming  of  networks  of  communicating  processes,  such  as  co-routines  and 
operating  systems. 

The  incorporation  of  data  structure  operations  into  data  flow  languages  has 
influenced  architectural  designs.  In  theory,  data  flow  operators  using  data  structures 
would  need  to  pass  copies  of  entire  structures  among  themselves.  However, 
Ackerman  [1]  has  specified  a structure  processing  facility  which  allows  pointers  to 
structures  to  be  passed,  but  still  guarantees  that  no  program  observable  side-effects 
may  be  caused  by  a structure  operation.  The  facility  Is  designed  to  process  many 
operations  concurrently. 
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1 .3  ADFL  - An  Applicative  Data  Flow  Language 

ADFL,  Applicative  Data  Flow  Language,  is  a simplification  of  VAL,  the 

value-oriented  data  flow  language  being  developed  by  Ackerman  and  Dennis  [2J.  A 

BNF  specification  of  the  syntax  of  ADFL  follows: 

exp  id  j const  | exp  , exp  | oper(exp)  | let  idlist  = exp  in  exp  | 
if  exp  then  exp  else  exp  | for  idlist  = exp  do  iteration 

iteration  ::=  exp  | iter  exp  | let  idlist  = exp  in  iteration  | 
if  exp  then  iteration  else  iteration 

id  ::=  "programming  language  identifiers" 

idlist  id  { , id  } 

const  ::=  "programming  language  constants" 
oper  ::=  "programming  language  operators" 

The  most  elementary  expressions  of  ADFL  are  identifiers  and  constants. 
Tuples  of  expressions  are  also  expressions.  One  such  expression  is  "x,  6".  The 
application  of  an  operator  to  an  expression  is  an  expression.  Although,  the  BNF 
specification  only  provides  for  operator  applications  in  prefix  form,  such  as  "+(x,  5)"; 
applications  in  infix  form,  such  as  "x  + 5",  are  considered  acceptable  equivalents 
(sugarings)  and  will  be  used  in  example  ADFL  programs.  All  operators  of  ADFL  are 
required  to  be  determinate  and  therefore  characterizable  by  mathematical  functions. 
We  will  not  attempt  to  completely  specify  the  class  of  operators  and  constants.  It  is 
assumed  that  at  least  the  usual  arithmetic  and  boolean  operators  and  constants  are 
present. 

Since  ADFL  is  applicative,  it  provides  for  the  binding,  rather  than  the 
assignment,  of  identifiers.  Evaluation  of  the  binding  expression: 
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let  y,  z = x + 5,  6 in  y * z 

implies  the  evaluation  of  "y  * z"  with  y equal  to  "x  + 5"  and  z equal  to  6.  The  result  of 
binding  is  local:  the  values  of  y and  z outside  the  binding  expression  are  unchanged. 

ADFL  contains  a conventional  conditional  expression,  but  has  an  unusual 
iteration  expression.  The  evaluation  of  the  iteration  expression: 
for  idlist  - exp  do  iteration 

is  accomplished  by  first  binding  the  iteration  identifiers,  the  elements  of  idlist,  to  the 
values  of  exp.  Note  from  the  BNF  specification  of  iteration,  that  the  evaluation  of  the 
iteration  body  will  ultimately  result  in  either  an  expression  or  the  "application"  of  a 
special  operator  iter  to  an  expression.  This  application  to  iter  is  actually  a tail 
recursive  [ 1 7]  call  of  the  iteration  body  with  the  iteration  identifiers  bound  to  the 
"arguments"  of  iter.  The  iteration  is  terminated  when  the  evaluation  of  the  iteration 
body  results  in  an  ordinary,  non  iter,  expression.  The  value  of  this  expression  Is 
returned  as  the  value  of  the  iteration  expression.  The  following  iteration  expression 
computes  the  factorial  of  n: 
for  i,  y = n,  1 

do  if  i > 1 then  iter  i - 1,  y * i else  y 

In  conventional  languages  execution  exceptions,  such  as  divide  by  zero 
errors,  are  generally  handled  by  program  interrupts.  This  solution  is  inappropriate  for 
data  flow  since  there  is  no  control  flow  to  interrupt.  In  ADFL  execution  exceptions  are 
handled  by  generating  special  error  values.  For  example,  evaluation  of  "5/0"  yields 
the  special  value  "DivideByZero".  We  will  not  attempt  to  specify  a large  class  of  error 
values  and  the  result  of  operator  application  to  error  values  here.  A detailed 
specification  of  this  method  of  error-handling  is  given  in  the  documentation  of  VAL  [2]. 
Only  one  error  value,  err,  will  be  specifically  used  in  the  formalism  contained  in  this 
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thesis.  The  result  of  evaluating  conditional  expressions  or  iteration  bodies  In  which 
the  predicate  is  neither  true  or  false  is  a tuple  containing  err  as  each  component. 

1 .4  The  Semantics  of  Data  Flow  Programs 

The  operational  semantics  of  a data  flow  program  is  a formal  simulation  of 
the  execution  of  the  program's  data  flow  graph.  The  formal  modeling  of  graph 
execution  is  non-trivial.  The  "state"  of  an  executing  graph  may  be  considered  a 
snapshot  of  the  tokens  contained  on  the  links  of  the  graph  [7].  The  firings  of 
operators  transform  the  graph  through  an  execution  sequence  of  snapshots.  Since 
most  adjacent  pairs  of  operator  firings  are  independent,  their  places  within  an 
execution  sequence  may  be  interchanged.  Thus,  many  execution  sequences  may 
represent  the  "same"  computation. 

During  a graph  execution,  an  operator  receives  at  each  input  port  a history, 
possibly  empty,  of  input  values  and  produces  at  each  output  port  a history  of  output 
values.  An  operator  is  determinate  if,  for  every  tuple  of  input  histories,  one  for  each 
input  port,  a unique  tuple  of  output  histories  is  produced.  The  mapping  from  input 
history  tuples  to  output  history  tuples  is  the  history  function  of  the  determinate 
operator.  The  determinacy  of  an  operator  cannot  depend  on  the  relative  timing  of 
values  received  on  different  input  ports.  Operators  with  time-dependent  behavior 
have  non-determinate  races  at  their  input  ports. 

Pntii  [1G]  proved  that,  if  all  operators  of  a graph  are  determinate,  the  graph 
itself  is  determinate.  Thus,  given  inputs  to  a determinate  graph,  it  Is  necessary  to 
examine  only  one  execution  sequence  to  derive  the  result  of  graph  execution. 
Kalin  [12]  further  simplified  this  derivation  by  noting  that  every  graph  operator, 
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through  its  history  function,  places  a relation  on  the  histories  of  its  input  and  output 
links  and  that,  consequently,  the  history  functions  of  the  operators  form  a set  of 
simultaneous  equations  over  the  links  of  the  graph.  Using  Scott's  [16]  fixpoint  theory, 
Kahn  was  able  to  distinguish  the  solution  of  these  equations  which  corresponds  to 
graph  execution.  Because  programs  of  ADFL  are  determinate,  the  operational 
semantics  of  ADFL  may  be  stated  by  specifying  the  translation  algorithm  from  programs 
to  graphs  and  by  specifying  the  history  functions  of  the  operators  used  in  these 
graphs.  Kahn's  theory  may  be  used  to  obtain  the  function  implemented  by  a data  flow 
graph  following  operational  rules. 

1 .5  Synopsis  of  Thesis 

This  thesis  contains  a definition  of  the  operational  semantics  of  ADFL. 
These  semantics  may  be  used  in  formal  proofs  of  properties  of  ADFL  expressions  and 
their  graph  implementations.  In  Chapter  2,  a graph  assembly  language  for  specifying 
data  flow  graphs  is  introduced,  and  the  algorithm  for  translating  ADFL  programs  into 
data  flow  graphs  is  described.  The  translation  algorithm  is  a function  f)  mapping  ADFL 
expressions  into  graphs.  In  Chapter  3,  the  data  flow  operators  used  to  implement 
ADFL  programs  are  specified,  the  semantic  function  Q mapping  graphs  into  their 
history  function  specification  of  execution  is  derived  by  use  of  Kahn's  theory,  and  the 
operational  semantics  of  an  ADFL  iteration  expression  is  derived  by  application  of 
()  ° „V  to  the  expression.  Conclusions  and  suggestions  for  future  research  are 
contained  in  Chapter  4. 
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2.  J7s  The  Translation  Algorithm 

The  translation  algorithm  is  the  "compiler"  of  ADFL.  It  Is  a function  f)  which 
maps  ADFL  expressions  into  data  flow  graphs.  In  this  chapter  a language  for 
constructing  data  flow  graphs  is  described  and  then  used  to  specify  the  translation 
process.  Since  the  primary  goal  of  this  thesis  is  stating  the  operational  semantics  of 
ADFL,  many  ordinary  compiler  features  such  as  compile-time  type  checking  are  ignored 
here. 

Formally,  a data  flow  operator  is  a history  function  from  tuples  of  histories 
to  tuples  of  histories.  The  complete  specification  of  the  semantics  of  the  various  data 
flow  operators  is  given  in  Chapter  3.  In  this  chapter,  concerned  solely  with  the 
connection  of  operator  ports  to  form  graphs,  it  suffices  to  be  able  to  determine  the 
labels  of  the  ports  of  each  operator.  This  information  is  available  through  two 
functions.  Given  a data  flow  operator  o,  IN(o)  is  the  set  of  labels  of  the  input  ports  of 
o,  OUT(o)  is  the  set  of  labels  of  the  output  ports.  It  will  be  assumed  that  the  ports  of 
data  flow  operators  corresponding  to  ADFL  operators  are  labeled  by  consecutive 
integers.  For  example,  IN(+)  = {1,2}  and  OUT(+)  = (1).  The  functions  #IN,  such  that 
#IN(o)  is  the  cardinality  of  IN(o),  and  #OUT,  defined  similarly,  will  also  be  used  in  graph 
construction. 

A data  flow  graph  has  four  constituent  parts:  operators,  input  ports,  output 
ports,  and  links.  The  links  of  a data  flow  graph  join  the  input  and  output  ports  of  Its 
operators.  Formally,  operator  interconnection  may  be  described  as  a relation  on 
operator  ports.  The  unlinked  operator  ports  are  the  ports  of  the  graph  itself.  Graph 
ports,  like  operator  ports,  are  labeled.  Therefore,  unlinked  operator  ports  must  be 
assigned  the  labels  they  assume  as  graph  ports.  Graph  port  assignment  may  be 
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described  as  a relation  on  graph  ports  and  operator  ports.  Unfortunately,  the  direct 
description  of  operator  interconnection  and  graph  port  assignment  by  relations  la 
difficult  to  write  and  comprehend.  For  this  reason,  graphs  generated  by  the  translation 
process  will  be  specified  by  use  of  a graph  assembly  language. 

2.1  A Graph  Assembly  Language 

The  graph  assembly  language  is  based  on  the  structural  description 
language  of  Ellis  [10].  It  is  not  a complete  data  flow  programming  language.  It 
contains  only  those  features  needed  to  provide  a convenient  and  adequate 
specification  of  the  translation  process. 

There  are  four  components  to  each  graph  description  of  the  graph  assembly 

language.  The  first  three  name  the  input  ports,  output  ports,  and  links  of  the  graph. 

The  fourth  specifies  the  operators  of  the  graph  and  their  interconnection. 

Syntactically,  the  form  of  a graph  description  is: 

inputs:  ... 
outputs:  ... 
links:  ... 
operators: 

The  ellipses  in  the  above  form  are  filled  by  appropriate  lists.  The  inputs  and  outputs 
lists  contain  the  labels  of  the  graph  input  and  output  ports.  These  are  the  only  lists 
available  outside  the  graph  definition.  The  functions  IN  and  OUT  are  extended  to 
graphs  by  defining  IN  to  map  each  graph  into  the  set  of  Its  input  port  labels,  as  given 
by  the  inputs  list,  and  OUT  to  map  each  graph  Into  the  set  of  its  output  port  labels. 


The  links  and  operators  lists  specify  operator  interconnection  and  graph 
port  assignment.  All  links  of  the  graphs  are  labeled  and  enumerated  *n  the  links  lists. 
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Operator  ports  are  connected  by  being  assigned  to  the  same  Jink.  These  assignments 
are  made  in  the  operators  list.  One  and  only  one  operator  output  port  and  at  least  one 
operator  input  port  must  be  assigned  to  a link.  If  more  than  one  Input  port  Is  assigned, 
a copy  operator  is  used  to  distribute  the  outputs  to  all  the  input  ports. * The 
assignment  of  an  unlinked  operator  port  to  its  graph  port  label  is  also  made  In  the 
operators  list. 

The  operators  of  the  graph  and  the  assignment  of  operator  ports  to  graph 

links  and  ports  are  given  In  the  operators  list.  For  each  instance  of  an  operator  o the 

operators  list  contains  the  element: 

o inputs:  ... 
outputs:  ... 

The  assignment  of  a graph  link  or  input  port  a to  an  operator  input  port  a is  indicated 
by  including 
a -*  a 

in  the  Inputs  list.  The  assignment  of  an  operator  output  port  a to  a graph  link  or  output 
port  a is  indicated  by  including 
a •*  a 

in  the  outputs  list.  The  arrow  -*  always  points  in  the  direction  of  data  flow.  This 
convention  allows  a graph  input  port  and  a graph  output  port  to  share  the  same  label 
without  any  ambiguity  of  assignment  occurring.  It  is  occasionally  necessary  or 
convenient  to  connect  graph  ports  and  links.  This  is  done  by  including  an  assignment 
as  a separate  element  of  the  operators  list.  Note  that  by  use  of  the  functions  IN  and 
OUT,  it  is  possible  to  determine  if  proper  assignments  are  made  for  all  operator  ports. 


1.  The  link  of  Dennis  [7]  is  the  copy  operator  used  for  this  purpose. 
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In  Figure  2.1,  a graph  description  which  generates  the  distance  data  flow 
graph  of  Chapter  1 is  given.  Note  how  the  connection  of  the  output  port  of  the 
leftmost  - operator  through  a copy  operator  to  both  input  ports  of  the  leftmost  * 
operator  is  specified.  First,  the  connecting  link  is  labeled  "a,".  The  Inclusion  of  the 
assignments  "1  -*  a,"  in  the  outputs  list  of  the  - operator  and  "a,  -♦  1M  and  "a,  -♦  2"  In 
the  inputs  list  of  the  * operator  completes  the  specification. 

The  translation  algorithm  is  defined  recursively.  The  data  flow  graph  of  an 
expression  Is  constructed  from  the  graphs  of  its  sub-expressions.  Three  extensions 
are  made  to  the  graph  assembly  language  to  allow  recursive  graph  definitions. 

First,  it  must  be  possible  to  construct  graphs  which  have  smaller  graphs  as 
their  components.  This  can  be  done  with  the  present  syntax  for  graph  definitions 
because  graphs  and  operators  have  the  same  external  Interface.  Both  receive  values 
at  labeled  input  ports  and  produce  values  at  labeled  output  ports.  Within  a graph 
definition  the  ports  of  component  subgraphs  can  be  assigned  to  graph  links  or  ports  in 
the  same  manner  ports  of  component  operators  are  assigned. 

Second,  it  must  be  possible  to  write  graph  definition  schemas  which 
incorporate  subgraphs  with  various  external  characteristics.  The  labels  of  the  ports  of 
a graph  or  operator  can  be  obtained  with  the  functions  IN  and  OUT.  Assignments  may 
be  made  to  these  ports  with  range  constructors.  A range  constructor  of  the  form: 

(a  e set)  item 

specifies  a list  which,  for  every  element  of  set,  has  an  occurrence  of  item  with  a 
replaced  by  that  element.  For  example: 

(/  € 1 ..  5)  / -»  a, 
is  equivalent  to: 
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1 -♦  or ,,  2 -♦  a2.  3 -►  a3.  4 ^ a4,  5 -♦  a5 

Generally,  range  constructors  are  used  to  construct  lists  over  ranges  of  Integers  or 
sets  of  input  or  output  port  labels.  A similar  constructor  Is  used  by  Hoare[11]  to 
specify  systems  of  communicating  processes. 

And  last,  it  must  be  possible  to  prevent  the  application  of  graph  definition 
schemas  in  certain  anomalous  situations.  For  example,  the  ADFL  expression: 
if  x,  y then  ...  else  ... 

is  invalid  and  little  is  gained  by  specifying  its  translation  into  a data  flow  graph.  A 
graph  definition  schema  may  be  restricted  by  the  addition  of  a fifth  top-level 
component  of  the  form: 

restriction:  predicate 

The  schema  is  appropriate  only  in  situations  where  the  restriction  predicate  is  true. 

In  Figure  2.2,  a recursive  definition  of  a graph  ♦ for  adding  n numbers  is 
given.  The  graph,  an  inverse  binary  tree  of  + operators,  is  recursively  generated  with 
two  *n/2  subgraphs  and  one  + operator.  The  n graph  input  ports  are  evenly  divided 
between  the  two  +n)2  subgraphs.  The  results  of  these  two  subgraphs  are  summed  by 
the  + operator.  The  definition  is  restricted  to  those  cases  where  n is  a power  of  two 
greater  than  two.  Presumably,  +2  is  the  usual  + operator. 

2.2  The  Structure  of  ADFL  Graphs 


The  remainder  of  this  chapter  is  devoted  to  a case  by  case  specification  of 
the  translation  function  for  ADFL.  f)  maps  expressions  and  maps  iteration  bodies 
into  corresponding  data  flow  graphs.  The  special  value  ERROR  denotes  the  result  of 
the  translation  of  invalid  expressions  or  iteration  bodies. 
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A graph  corresponding  to  an  ordinary  expression  or  iteration  body  has  an 
input  port  for  each  free  variable  of  the  expression  or  iteration  body  and,  if  needed,  an 
input  port  trigger  for  enabling  constants.  For  an  expression  exp  which  returns  n 
values  when  evaluated,  J7([exp]l  has  n output  ports  labeled  1 through  n.  There  are 
two  possible  results  of  evaluation  for  an  iteration  body,  results  to  be  re-iterated  or 
results  to  be  returned  as  the  results  of  the  containing  iteration  expression.  The  graph 
^iteration]  of  an  iteration  body  Iteration  has  a set  of  output  ports  for  each 
possibility  and  an  output  port  iter?  which  signals  which  possibility  has  occurred.  The  I 
ports,  II  through  I m,  are  for  values  to  be  iterated,  and  the  R ports,  R1  through  Rn,  are 
for  values  to  be  returned. 

The  translation  functions  and  7|  are  defined  recursively  on  the  eleven 
cases  of  the  DNF  specification  of  the  syntax  of  ADFL: 

exp  ::=  id  | const  | exp  , exp  | oper(exp)  | let  Idlist  - exp  in  exp  \ 
if  exp  then  exp  else  exp  | for  Idlist  - exp  do  iteration 

iteration  exp  ) iter  exp  J let  idlist  - exp  in  Iteration  \ 
if  exp  then  iteration  else  iteration 

2.3  The  Translation  of  Expressions  without  Iteration 

The  first  case  „7lDd]l>  illustrated  in  Figure  2.3,  is  the  most  simple.  Is 

the  graph  with  the  single  input  port  id,  one  output  port,  and  no  operators.  The  Input 
port  id  is  directly  connected  to  the  output  port. 

The  second  case  ?)$const%  illustrated  in  Figure  2.4,  is  almost  as  simple. 
7[[c onsf]J  is  the  constant  operator  const  with  Its  operator  ports  assigned  to  graph 
ports  with  the  same  labels.  The  operator  const  and,  consequently,  the  graph 
7 ([const])  produce  the  output  value  const  whenever  a trigger  value  Is  received. 
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The  graph  j7deArp1,  exp2]J,  defined  in  Figure  2.6,  contains  two  subgraphs, 
^[[expl]!  and  7 II exp2]].  Input  ports  of  either  subgraph  are  assigned  to  graph  Input 
ports  with  the  same  label.  The  graph  output  ports  are  formed  by  concatenating  the 
output  ports  of  the  component  subgraphs. 

7 1 [oper(exp)]],  shown  in  Figure  2.6,  is  formed  by  connecting  the  output 
ports  of  7le*p]l  to  the  input  ports  of  oper.  If  the  two  sets  of  ports  do  not  match, 
j7|[ope/-(exp)]]  is  ERROR. 

The  free  variables  of  the  expression  "let  idlist  ~ expl  In  exp2"  are  the 
free  variables  of  expl  plus  the  free  variables  of  exp2  not  appearing  In  Idlist.  The 
graph  7lDe*  Idlist  = expl  In  exp2j,  illustrated  In  Figure  2.7,  is  constructed  by 
connecting  the  /'th  output  port  of  ^ffexplj  to  the  Input  port  of  7tte*'P2]l  labeled  by 
the  /’th  identifier  of  Idlist.  Input  ports  of  7Ce'*,P2]]  unlabeled  by  an  identifier  of  idlist 
and  all  input  ports  of  7tte*Pl]l  are  assigned  to  graph  input  ports.  The  output  ports  of 
„7|[e*p2]J  are  assigned  to  the  graph  output  ports.  If  the  length  of  Idlist  does  not 
match  the  number  of  output  ports  of  ^7l[expl]l  or  if  some  identifier  In  Idlist  Is  unused 
in  7Ce*P2]J,  _7([let  idlist  = expl  in  exp2j  is  ERROR. 

The  graph  description  of  Figure  2.8  of  the  implementation  of  the  conditional 
expression  "if  expl  then  exp2  else  exp3"  Is  one  of  the  more  complicated.  Three 
subgraphs,  7l[expl] J,  7ll exp2]],  and  7tte*P3l)<  are  contained  in  this  graph.  Since 
the  predicate  expl  determines  which  of  exp2  and  exp3  is  selected  for  evaluation,  the 
enabling  of  the  result  expression  subgraphs,  7lle*p2])  and  7lIejlfP3]l.  must  be 
controlled  by  the  predicate  subgraph,  7(Le*Pl]l-  Th,s  control  Is  effected  by 
connecting  gates  controlled  by  the  predicate  subgraph  to  the  Input  and  output  ports  of 
the  result  expression  subgraphs. 
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Three  gates,  shown  with  their  firing  rules  in  Figure  2.9,  are  used.  The 
T gate  receives  a control  value  from  one  input  port,  shown  entering  the  gate 
horizontally,  and  a data  value  from  another  input  port.  The  data  value  is  passed  to  the 
output  ports  only  if  the  control  value  is  true.  If  the  control  value  is  false,  the  data 
value  is  simply  absorbed.  No  output  is  produced.  By  placing  a T gate  controlled  by  the 
output  of  on  each  input  path  of  _c7[[exp2]),  the  evaluation  of  exp2  can  be 

restricted  to  when  expl  is  true. 

The  role  of  the  control  value  is  reversed  in  the  F gate.  The  data  value  is 
passed  if  the  control  value  is  false  and  is  absorbed  if  the  control  value  is  true. 
F gate's  control  the  enabling  of  ^7[[exp3]l  in  the  same  manner  T gate's  control  the 
enabling  of  ^J^exp2\ 

The  output  ports  of  the  result  expression  subgraphs  are  merged  with 
M gate's.  The  M gate  receives  a control  value  which  determines  from  which  of  two 
input  ports  a data  value  should  be  absorbed  and  produced  as  an  output  value.  Each 
pair  of  output  ports  with  the  same  label  from  the  result  expression  subgraphs  are 
connected  to  a M gate  which  receives  the  output  of  the  predicate  subgraph  as  its 
control  value.  The  receipt  of  a true,  respectively  false,  predicate  value  causes  the 
data  value  from  j7lexp2|,  respectively  j7lexp3]|,  to  be  selected.  The  output  port  of 
the  M gate  is  assigned  to  a graph  output  port  of  the  shared  label. 

When  evaluation  of  the  predicate  yields  a value  other  than  true  or  false, 
neither  of  the  result  expressions  should  be  evaluated  and  err  should  be  generated  at 
each  graph  output  port.  This  error-handling  strategy  is  accomplished  by  requiring  that 
the  T gate  and  the  F gate  absorb  their  data  value  and  produce  no  output  value  and 
the  IVI  gate  absorbs  no  data  value  and  produces  an  err  output  when  a control  value 
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other  than  true  or  false  is  received. 

J=7l[if  expl  then  exp2  else  exp3]]  is  ERROR  if  expl  returns  more  than  one 
value  or  if  exp2  and  exp3  do  not  return  the  same  number  of  values. 

2.4  The  Translation  of  Iteration  Expressions 

The  translations  of  six  of  the  seven  types  of  expressions  has  been 
specified.  Only  the  iteration  expression  remains  untranslated.  However,  since  the 
iteration  expression  contains  an  iteration  body,  it  is  convenient  to  first  specify  the 
translation  of  the  four  types  of  iteration  bodies. 

Recall  that  the  output  port  iter?  of  the  data  flow  graph  of  an  iteration  body 
signals  whether  or  not  output  results  are  to  be  iterated  or  returned,  the  I output  ports 
are  for  values  to  be  iterated,  and  the  R output  ports  are  for  values  to  be  returned. 
The  function  IOUT,  respectively  ROUT,  is  defined  to  map  a graph  into  the  set  of  labels 
of  its  i,  respectively  R,  output  ports. 


The  graph  descriptions  of  the  iteration  bodies  "exp"  and  "iter  exp"  are 
given  in  Figures  2.10  and  2.1 1.  The  values  of  "exp"  are  to  be  returned.  The  values  of 
"iter  exp"  are  to  be  iterated.  Consequently,  in  j7|[[e*p]l  the  iter?  output  value  Is 
generated  with  a false  constant  operator,  while  in  j7|[[iter  exp]]  it  is  generated  with  a 
true  constant  operator.  Neither  graph  has  a "complete"  set  of  output  ports.  That  is, 
neither  contain  both  I and  R output  ports.  Output  port  i of  ^[[e^p]]  Is  assigned  to 
output  port  Hi  of  /7|[[exp]]  or  to  output  port  1/  of  ^([[iter  exp]]. 

The  iteration  body  "let  idtist  = exp  in  iteration " is  implemented  in  the  same 
manner  the  expression  "let  idlist  = exp  1 in  exp2"  is  implemented. 


- ■ 
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The  data  flow  graph  implementation  of  the  conditional  iteration  body 
"if  exp  then  iteration'i  else  iteration 2"  is  similar  to  that  of  the  conditional  expression. 
T gate's  and  F gate's,  controlled  by  the  outputs  of  the  predicate  subgraph,  T)  [[exp]), 
are  placed  on  the  input  paths  of  the  iteration  body  subgraphs,  ^7|([/fera(/onl]]  and 
,7,I[/ferat/on2]l.  so  that  the  predicate  can  enable  the  evaluation  of  the  selected 
iteration  body.  M gate's  control  the  graph  output  ports.  However,  there  are  two 
complications  in  the  use  of  M gate's  to  merge  the  outputs  of  the  iteration  body 
subgraphs.  First,  the  selected  iteration  body  subgraph  will  produce  outputs  at  either 
its  I or  its  R output  ports.  Consequently,  the  I and  R output  ports  must  be  controlled 
separately.  Second,  the  iteration  body  subgraphs  do  not  necessarily  have  both  I and  R 
output  ports.  In  Figure  2.12,  J7|[[if  exp  then  iteration}  else  iteration2]\  is  described 
with  the  assumption  that  both  iteration  body  subgraphs  have  both  I and  R output  ports. 
The  modification  required  in  other  situations  is  given  later  in  this  section. 


An  1C  gate  is  used  to  control  the  graph  output  ports.  The  1C  gate  has  three 
input  ports.  One  is  connected  to  the  output  of  the  predicate  subgraph,  and  the  other 
two  are  connected  to  the  iter?  outputs  of  the  iteration  body  subgraphs.  The  1C  gate 
also  has  three  output  ports.  One  is  assigned  to  the  graph  iter?  output  port,  a second 
is  the  I control  value  for  IV1  gate's  connected  to  the  graph  I ports,  and  a third  is  the  R 
control  value. 


The  1C  gate  has  the  following  firing  rule.  The  output  of  the  predicate 
subgraph  acts  as  a control  value.  It  determines  from  which  iteration  body  subgraph  an 
iter?  value  should  be  absorbed.  The  absorbed  iter?  value  signals  whether  outputs  are 
being  produced  at  the  I or  the  R output  ports.  This  value  is  output  as  the  graph  Iter? 
output  value  and  determines  whether  the  predicate  value  should  be  transmitted  as  the 
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I or  as  the  R control  value. 

If  the  predicate  value  is  neither  true  or  false,  a false  graph  Iter?  output  Is 
generated  to  terminate  the  iteration,  and  err  values  are  produced  at  the  graph  R 
ports.  To  accomplish  this,  err  is  transmitted  as  the  R control  value  and  false  Is 
transmitted  through  the  graph  iter?  port.  A formal  definition  of  the  1C  gate  is  given  in 
Chapter  3.  The  following  table  summarizes  its  firing  rules. 


predicate 

/7|([/feraf/onl]] 

^J$iteration2]\ 

graph 

1 

R 

control 

iter? 

iter? 

iter? 

control 

control 

true 

true 



true 

true 



true 

false 

— 

false 

— 

true 

false 

— 

true 

true 

false 

— 

false 

— 

false 

false 

— 

false 

error 



. 

false 

. _ 

err 

If  both  iteration  body  subgraphs  have  I output  ports,  these  ports  must  match 
in  number  and  must  be  connected  through  M gate's,  controlled  by  the  I control  value, 
to  the  I ports  of  the  graph.  If  only  one  subgraph  has  I output  ports,  the  IVI  gate's  are 
omitted  and  the  I output  ports  of  that  subgraph  are  assigned  to  the  I output  ports  of 
the  graph.  If  both  subgraphs  have  R output  ports,  these  ports  are  similarly  connected 
to  the  R output  ports  of  the  graph.  If  only  one  subgraph  has  R output  ports;  E gate's, 
controlled  by  the  R control  value,  are  placed  between  the  subgraph  and  graph  R ports. 
Whenever  the  E gate  receives  a Boolean  control  value,  it  absorbs  a data  value  and 
produces  it  as  output.  Whenever  the  E gate  receives  any  other  control  value,  it 
absorbs  no  data  value  and  produces  err  as  output. 

All  graphs  described  up  to  this  point  have  been  acyclic.  If  values  are 
"dropped"  in  the  input  ports,  the  results  will  eventually  "drop"  out  the  output  ports. 
The  reader  should  be  convinced  that  these  graphs  compute  their  intended  functions. 
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These  graphs  can  also  execute  in  pipeline  fashion.  The  computation  of 
successive  sets  of  inputs  will  pipeline  through  the  graph  and  eventually  produce 
successive  sets  of  results.  The  computation  of  a later  set  of  inputs  always  strictly 
follows  a computation  of  an  earlier  set  except  when  the  computations  utilize  different 
subgraphs  during  the  evaluation  of  a conditional  expression  or  iteration  body.  Within 
the  implementation  of  a conditional  expression,  the  M gate's  merge  the  output  ports  of 
such  subgraphs  and,  using  the  pipelined  result  of  predicate  evaluations,  restore  the 
original  order.  Within  the  implementation  of  a conditional  iteration  body,  the  two 
computations  are  not  necessarily  merged,  but  the  values  of  the  iter?  output  port 
reflect  the  branches  pursued  by  the  computations. 

The  iteration  expression  "for  idlist  = exp  do  iteration " is  translated,  as 
shown  in  Figure  2.13,  into  a cyclic  data  flow  graph  containing  the  initialization 
expression  subgraph,  f7E[e^pll.  the  iteration  body  subgraph,  j7|l[/teraf/on]),  FM  gate's, 
and  FS  gate's.  A FM  gate  is  a M gate  with  a built-in  initial  control  value  of  false. 
After  "absorbing"  this  initial  control  value  and  passing  its  selected  data  value,  the 
FM  gate  behaves  like  the  M gate.  The  FS  gate  has  one  control  input  port  and  one 
data  input  port.  It,  too,  has  the  built-in  initial  control  value  false.  On  receipt  of  a 
false  control  value,  the  FS  gate  absorbs  a data  input  value,  stores  it  in  an  internal 
register,  and  passes  it  through  the  gate  output  port.  On  receipt  of  a true  control 
value,  no  data  value  is  absorbed,  but  on  output  of  the  stored  value  is  produced. 

The  sets  of  identifiers  in  idlist,  output  ports  of  ^[[e^p]].  and  I output  ports 
of  J $_iteralion$  must  all  be  of  equal  cardinality,  and  the  identifiers  of  idlist  must  all 
be  free  in  the  iteration  body.  Otherwise,  ^7[[for  idlist  = exp  do  iteration ]]  is  ERROR. 


The  input  port  of  the  iteration  body  subgraph  labeled  by  the  f'th  identifier  of 
idlist  is  connected  to  an  FM  gate.  The  input  Dorts  of  this  FM  gate  are  connected  to 
the  iter?  and  1/  output  ports  of  the  iteration  body  subgraph  and  the  I output  port  of  the 
initialization  expression  subgraph  so  that  input  is  first  accepted  from  the  initialization 
subgraph  and  then  is  accepted  from  the  iteration  subgraph  as  long  as  the  value  true  is 
produced  at  the  iter?  port.  This  corresponds  to  evaluating  the  iteration  body  with 
successive  iteration  body  results  until  an  ordinary,  iter-less,  expression  is  returned. 
The  value  of  that  ordinary  expression  leaves  the  iteration  body  subgraph  through  its  R 
output  ports.  These  R output  ports  are  assigned  to  the  graph  output  ports. 

Every  evaluation  of  the  iteration  body  requires  the  values  of  its  free 
identifiers.  The  values  of  the  free  identifiers  not  appearing  in  idlist  must  be 
generated  for  each  iteration  by  FS  gate's.  The  input  ports  of  the  iteration  body 
subgraph  labeled  by  these  identifiers  are  connected  to  FS  gate's  controlled  by  the 
iter?  output.  Initially,  the  FS  gate  accepts,  and  stores,  an  input  from  a graph  input 
port.  Each  time  true  is  produced  at  the  iter?  port,  the  FS  gate  passes  its  retained 
value  into  the  iteration  body. 

During  the  evaluation  of  an  iteration  expression,  successive  iterations  need 
not  proceed  in  lock-step  fashion.  If  the  iter?  value  is  produced  before  all  the  values 
to  be  re-iterated  are  produced,  separate  iterations  may  pipeline  through  the  iteration 
body. 

When  the  evaluation  of  the  iteration  expression  is  completed,  false  is 
produced  at  the  iter?  port,  and  the  FM  gate's  and  FS  gate's  once  again  have  a false 
control  value  with  which  to  begin  another  evaluation.  In  Chapter  3,  the  data  flow  graph 
translation  of  the  iteration  expression  is  shown  to  satisfy  its  Intended  function. 
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All  cloven  coses  exhausted,  the  specification  of  the  translation  algorithm  is 
completed.  Every  expression  or  iteration  body  of  AOFL  has  been  implemented  as  a 
data  flow  graph  with  an  input  port  for  each  free  variable  of  the  expression  or  iteration 
body  and,  optionally,  an  input  port  trigger  for  enabling  constants.  An  informal 
description  of  the  operational  semantics  of  these  data  flow  graphs  has  also  been 
given.  In  Chapter  3,  the  operational  semantics  of  data  flow  graphs  will  be  formally 
specified.  Those  semantics  in  conjunction  with  the  translation  algorithm  will 
constitute  the  operational  semantics  of  AOFL. 


Figure  2.1 . Distance  Data  Flow  Graph 

inputs:  xl , x2,  x3,  x4 
outputs:  z 

links:  a,,  c*2,  a3,  ci4,  c*6 

operators: 

- inputs:  xl  -»  1,  x2  -»  2 
outputs:  1 -»  a, 

- inputs:  yl  -♦  1,  y2  -♦  2 
outputs:  1 -♦  o2 

* inputs:  a,  -♦  1,  a,  -»  2 
outputs:  1 -♦  a3 

* inputs:  a2-*  1 . a2  -*  2 
outputs:  1 -*  «4 

+ inputs:  «3  -♦  1,  a4  -*  2 

outputs:  1 -♦  a, 

0 

sqrt  inputs:  a5  -♦  1 
outputs:  1 -»  z 
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Figure  2.2.  +n 

restriction:  n = 2m  A n > 2 
inputs:  (/'  e 1 ..  n)  / 
outputs:  1 
links:  a ,,  «2 
operators: 

*n/2  inputs:  ( i el..  n/Z)  i -*  I 
outputs:  1 -»  a1 

+n/2  inputs:  (/el.,  n/2)  i+n/2  -*  I 
outputs:  1 -*  a2 
+ inputs:  a,  -♦  1,  a2  -»  2 
outputs:  1 -»  1 


1 ..  n/2  n!2+y  ..  n 


Figure  2.3.  ^([/t/]] 


inputs:  id 
outputs:  1 
operators: 
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Figure  2.4.  ^{[constj 

inputs:  trigger 
outputs:  1 
operators: 

const  inputs:  trigger  •*  trigger 
outputs:  1 -*  1 


Figure  2.5.  ^[exp1!,  exp2j 

inputs:  (a  e IN°j7l[expl]]  U IN®.:7([e*p2]])  a 

outputs:  (/el..  #OUT®/7([ex,pl]l  ♦ #OUT»j7([exp2]l)  / 

operators: 

^Cex'Pl]]  inputs:  (a  e IN®  j7([e*pl]))  a -*  a 

outputs:  (/'  e OUToj^fexpl]])  ( *♦  / 


,r7([exp2]l  inputs:  (a  e IN°j7[[e>fp2]])  a -*  a 

outputs:  (/'  e OUT®j7[[e*p2]l)  / •*  i * #0UT®^7lIexpl]l 
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Figure  2.6.  ^ffoperCexp)]] 

restriction:  OUT®  ^ffeArpJ  = in(oper) 
inputs:  (a  e IN® /7[[oArp]])  a 
outputs:  (/  e OUT(oper))  / 
links:  (/'  e in(oper))  a, 
operators: 

/7l[e*p]]  inputs:  (a  € IN®  7[[e*p]])  a -»  a 

outputs:  (/'  e OUT°j7[[e>rp]])  / -♦  a, 
opcr  inputs:  (/'  e IN(oper))  a,  -»  / 


outputs:  (/  e OUT(oper))  / -♦  / 


Figure  2.7.  /7[[let  /cf  1 , ....  idn  = e*p1  in  exp2]j 

restriction:  #OUT®j7[[e*pl]]  = n A {/dl idn)  c IN®j7[[exp2]l 

inputs:  (a  € IN®  ^ffexpl  ]j  U (IN®  - {/dl,  ....  Idn}))  a 

outputs:  (/  e OUToj^ITe*^]])  / 
links:  (/'  e 1 n) 
operators: 

.7[[e*PlIl  inputs:  (a  € IN® J7[[e^pl]l)  a -♦  a 
outputs:  (/  e 1 ..  n)  i -*  a, 


=7[[e*p2]]  inputs:  (a  e ,i7([exp2]l  - (fdl /dn})  a -*  a,  (I  e 1 ..  />)  or,  -*  /<// 

outputs:  (/  e OUT°j7[[exp2]])  i ■*  I 
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Figure  2.8.  j7[[if  exp  1 then  exp2  else  exp3j 

restriction:  OUTo^lJexplJ  = (1)  A OUT®.1? [[exp2])  = OUT*j7[[eA’p3]l 
inputs:  (a  e IN'J^Iexpl]]  U IN®„:7l[exp2]]  U IN®  './l[exp3]))  a 
outputs:  (/'  € OUT® j7([exp23J)  i 

links:  a.  (a  e IN® ^l[exp2]])  (a  e IN«j7l[exp331)  0^, 

(/  e OUT® '7([exp2]])  -vy.  (i  e OUT»;7|[exp3]])  7* 
operators: 

/7[[expl]J  inputs:  (a  € IN®^7|[expl]J)  a -»  a 
outputs:  1 -*  a 

(a  e IN® J=7[[exp2]])  T gate  inputs:  a -*  1,  a-*  2 

outputs:  1 -»  dJa 

(a  e INo.^IexpS]!)  F gate  inputs:  a -*  1,  a -»  2 

outputs:  1 -*  0fa 

j7[[exp2]l  inputs:  (a  e IN®^7[[exp2|)  <3^  -*  a 

outputs:  (/  e OUT®j7[[exp2]])  / -♦  7j 
/7[[exp3]]  inputs:  (a  e IN®y7ttexp3]l)  &f3-*  a 

outputs:  (>  e OUT®j9([exp3]))  i -*  7 * 

(/  e OUT® j7([exp2]))  IV1  gate  inputs:  a -»  1, 7j  -»  2,  7*  -*  3 

outputs:  1 -»  / 
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Figure  2.9.  Gates  for  Implementing  Conditional  Expressions 
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Figure  2.10.  j7([[exp]l 

inputs:  (a  e IN®j7|Ie*p]J  U {trigger})  a 
outputs:  (i  e OUT®  ^[[exp]])  R i,  iter? 
operators: 

false  inputs:  trigger  -*  trigger 
outputs:  1 -»  iter? 

^7[[exp])  inputs:  (a  e IN®  j7([exp]l)  a -»  a 

outputs:  (/'  e OUTo^([exp]l)  / -♦  R/ 


Figure  2.1 1.  j^ittiter  exp]) 

inputs:  (a  e IN«  ^Jexp]]  U {trigger})  a 
outputs:  (/  e OUTo  ^lIexp]))  I i,  iter? 
operators: 

true  inputs:  trigger  -*  trigger 
outputs:  1 -*  iter? 

.^ITexp]]  inputs:  (a  e IN®  ^([exp]])  a -*  a 

outputs:  (/  e OUT»j7Hexp]l)  / -*  1/ 


L 
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Figure  2.12.  j7|E'f  exp  then  iteration 1 else  ileralion2§ 

restriction:  Ol)To  ~7[[o>rp]]  = {1}  A OUT jUrter at /on  1 ]]  = OUT°^|[[/terat/on2]] 
inputs:  (a  e IN^^Iexp]]  U IN°/7||[^eraf/onl]l  U IN°^|[[/Jerat/,on2]])  a 
outputs:  (a  € OUJ°f7|[[*tera(/on1  J)  a 

links:  «.  o',  aR,  (a  e IN°,7|[['terat/onl]))  0],  (a  e ^iterationZj)  6\, 

(a  e OUT®^7|(['ferat/onl]])  7j,  (a  e OUT«.7|([/feral/on2]|)  7jj 
operators: 

7[[e^p]l  inputs:  (a  e IN0 .7  [[exp]])  a 
outputs:  1 -*  a 

(a  € INo  7|I'<era(/on1  ]])  T gate  inputs:  a -»  1,  a -*  2 

outputs:  1 -» /3] 

(a  e IN®j=7|C^erat/on2]l)  F gate  inputs:  a -»  1,  a -+  2 

outputs:  1 -» 

,7[['feraf/on1  ]]  inputs:  (a  e IN°7|[[,*era*'on1]])  @1  "*  a 

outputs:  (a  e OUT»j7|([^e/-a(/on1  ]])  a -♦  7^ 

_7l'feraf/on2]]  inputs:  (a  € IN®,7|[['ierat,on2]])  0*  -♦  a 

outputs:  (a  e OUT®7|tt*terat'on2]l)  a -♦  7^ 

1C  gate  inputs:  o -»  1, 7jter?  -»  2,  7^|er,  -*  3 
outputs:  1 -»  iter?,  2 3 -»  aR 

(1/  e IOUT®J=7|I['Terat/on  1 J)  M gate  inputs:  a1 -+  1, 7},-*  2,  7^ -»  3 

outputs:  1 -*  1/ 

(R/  € ROUT® „7|I['terat/onl]l)  IVI  gate  inputs:  1,'V5/-2.7^-»3 

outputs:  1 -*  R / 


f 
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Figure  2.1  3.  .^[[for  id  1 idn  = exp  do  iteration}} 

restriction:  n ~ POUT° j7  [[exp]]  = PIOUT®  j9||[fteraf/on]]  A {id},  ....  idn } c INo^^exp]] 
inputs:  (a  e IN^^Jexp]]  U (IN°^7|H/terat/on]]  - {id},  ....  idn})  a 
outputs:  (R/  e ROUTo^iH/Jerai/onl)  / 

links:  (/'el.,  n)  o,,  (a  e IN»^7|([/terat/on]])  j3a.  (/  e 1 ..  n)  7/t  7|lw? 
operators: 

V[[eAfp]l  inputs:  (a  e INo^tte^pJ)  a -♦  a 
outputs:  (/'  el  ..  n)  i -*  a, 

(/  el  ..  n)  FM  gate  inputs:  7|(ef7  ->  1 , 7,  -*  2,  a,  -♦  3 
outputs:  1 -♦  0l(jl 

(a  e (IN°  ^il^eraf/on]!  - {id}, ....  idn}))  FS  gate  inputs:  7|(er7  -»  1,  a -»  2 

outputs:  1 -*  0a 

^iteration]}  inputs:  (a  e IN“  ^[[/leral/on]])  (9 a -»  a 

outputs:  iter?  -♦  7Ww?p  (/'  e 1 ..  n)  I / -»  7f, 


w 
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3.  O'.  The  Operational  Semantics 

In  this  chapter,  a function  ()  mapping  data  flow  graphs  into  their  operational 
characterizations  is  given.  Operational  semantics  are  defined  using  Kahn's  [12]  formal 
model  of  parallel  computation.  Each  data  flow  operator  or  graph  is  characterized  by  a 
history  function  mapping  tuples  of  input  histories  into>tuples;o{'Output  histories.  The 
history  function  of  a graph  is  derived  using  the  history  functions  of  its  operators.  Kahn 
originally  used  his  theory  to  characterize  processes  written  in  an  ALGOL-like  language 
augmented  with  get  and  put  statements  for  receiving  and  transmitting  values  on 
queues  and  to  derive  the  result  of  interconnecting  such  processes.  The  contrast 
between  Kahn's  level  of  application  and  ours  illustrates  the  relative  concurrency 
obtained  with  data  flow  and  sequential  control  flow  program  execution.  In  Kahn's 
sequential  control  flow  application,  concurrency  is  limited  to  the  simultaneous 
execution  of  processes  consisting  of  several  programming  language  statements; 
where,  in  our  data  flow  application,  concurrency  occurs  at  even  the  most  elementary 
level  of  expression  evaluation. 

The  first  section  of  this  chapter  describes  Kahn's  theory  as  applied  to  data 
flow  graphs.  The  formal  characterization  of  operators  and  graphs,  the  restrictions 
placed  on  the  behavior  of  operators,  the  method  for  deriving  the  semantics  of  graphs, 
and  the  closure  properties  of  this  characterization  of  operators  and  graphs  are  given. 
Readers  familiar  with  Kahn's  theory  may  wish  to  proceed  to  the  second  section.  The 
second  section  specifies  the  semantics  of  operators  used  in  graph  implementations  of 
ADFL  expressions.  The  third  and  final  section  illustrates  the  application  of  this  theory 
to  derive  the  semantics  of  an  ADFL  iteration  expression. 
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3.1  Kahn's  Semantics  of  Data  Flow  Graphs 

Tlte  operational  semantics  of  a data  flow  operator  o is  given  by  a history 
function  Olio]]  mapping  input  history  tuples  into  output  history  tuples.  For  each  Input 
history  tuple  X,  representing  the  history  of  values  received  at  the  input  ports  of  o,  the 
output  history  tuple  0[[o]](X)  represents  the  history  of  values  produced  at  the  output 
ports  of  o in  response  to  X.  Input  history  tuple  X has  as  Its  components  a history,  a 
possibly  infinite  sequence  of  values,  for  each  port  of  o.  Formally,  input  history  tuple  X 
is  a function  which  maps  each  input  port  label  a of  o into  the  input  history  X(a),  often 
denoted  X , received  at  that  port.  Output  history  functions  are  defined  similarly. 

Not  all  operators  may  be  characterized  by  Kahn's  history  functions.  In 
particular,  only  determinate  operators  which  for  each  input  history  have  only  one 
possible  output  history  may  be  characterized  thus./.  Since  only  determinate  operators 
were  used  in  Chapter  2 to  construct  graph  implementations  of  ADFL  expressions,  the 
history  function  characterization  is  adequate  for  describing  the  operational  semantics 
of  ADFL.  There  are  two  other  requirements  which  operators  must  satisfy  in  order  that 
fixpoint  methods  may  be  used  to  determine  the  result  of  their  interconnection. 
However,  these  requirements  are  not  restrictions  but  rather  a formal  statement  of 
some  properties  of  which  history  functions  of  physically  realizable  data  flow  operators 
must  satisfy. 

First,  the  domain  or  range  of  a history  function  must  be  a complete  partially 
ordered  set  with  a least  element.  We  review  the  definition  of  a complete  partial  order. 

Del  initiorr.  A relation  E on  a set  /)  is  a partial  order  If  E is: 

( 1 ) ,  reflexive,  V x e A,  x E x, 

(2) ,  antisymmetric,  V x,  ye/1,  xEyAyEx-*x  = y,  and 

(3) ,  transitive,  Vx,  y,  z e A,  xEyAyEz-*xEz. 
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Def  inition:  An  upper  bound  of  a subset  £ of  A is  an  element  x of  A at  least  as  great 
as  any  element  of  E,  i.  e.  V y e E , y E x.  Often,  this  is  denoted  £ E x. 

Lower  bounds  of  E are  defined  and  denoted  analogously. 

Def  inition  and  Theorem : For  every  subset  £ of  A there  is  at  most  one  element  x of  A 
that  is  both  an  upper  bound  of  £ and  a lower  bound  of  the  set  of  upper  bounds  of  £, 
/.  e.  £ E x E { y | £ £ y}.  Should  such  an  element  exist,  it  is  the  feast  upper  bound  of  £ 
and  is  denoted  LI  £. 

The  greatest  lower  bound  of  £ is  defined  analogously  and  denoted  (1  £. 

Definition-.  Given  an  increasing  sequence  x,  E x2  E ...  of  A,  U {*,,  x2,  ...},  if  it  exists, 
is  denoted  LJ  x,  and  called  the  limit  of  x,. 

Def  inition:  A partial  order  E on  A is  complete  if  every  increasing  sequence  has  a limit. 

Let  V be  the  set  of  elementary  data  flow  values  such  as  integers  and 

booleans.  This  set  contains  all  values  that  could  be  passed  between  data  flow 

operators  including  error  values,  and  the  trigger  token.  The  set  of  all  histories  of  data 

flow  values,  that  is,  the  set  of  all  finite  and  countably  infinite  sequences  of  data  flow 

values,  will  be  denoted  V^.  may  be  ordered  by  the  prefix  ordering: 

Definition:  Given  two  sequences  x and  y of  V^,  x E y if  x is  a prefix  of  y,  that  Is, 
there  exists  a sequence  z such  that  x*z  = y. 

It  is  easy  to  verify  that  E is  a complete  partial  order  on  V^.  The  least  element  of 
is  the  empty  history,  f. 

Recall  that  a history  tuple  is  a function  from  a set  of  input  or  output  port 

labels  to  , the  set  of  histories.  Consequently,  the  domain  or  range  of  a history 

function  is  the  set  of  all  functions  from  a set  A of  input  or  output  port  labels  to  V^. 

A 

This  set  is  denoted  l/60  . The  complete  partial  order  E on  V03  can  be  naturally 
extended  to  l/^  by  defining  X E Y,  for  history  tuples  X and  Y of  l/^*,  if  every 
component  of  X is  less  than  the  corresponding  component  of  Y,  that  is,  if  for  all  a in  A, 
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Xa  E Ya.  Again,  it  can  be  easily  verified  that  Eisa  complete  partial  order  on  \/U)A.  The 
least  element  of  is  lA,  the  empty  history  tuple  which  has  the  empty  history  as 
each  of  its  components. 

The  second  requirement  of  fixpoint  theory  is  that  history  functions  be 
continuous.  A function  F is  continuous  if,  for  every  increasing  sequence  r,  E E 
F(U  x t)  = LI  F(x.).  A continuous  function  is  also  mono^onlc,  that  Is,  x Q y implies 
Fix)  E F(y).  Monotonicity  and  continuity  reflect  physical  properties  of  operator 
Implementations. 

Monotonicity  implies  that  the  more  input  an  operator  receives,  the  more 
output  it  will  produce.  This  requirement  reflects  several  implementation  considerations. 
First,  an  operator  cannot  "withdraw"  output  values.  Second,  and  perhaps  most 
important,  an  operator  may  process  its  input  values  as  they  are  received  without  the 
possibility  that  output  produced  in  response  to  initial  input  will  violate  the  ultimate 
output.  If  operators  were  not  allowed  this  freedom  and  had  to  receive  their  entire 
input  before  producing  any  output,  the  potential  concurrency  of  data  flow 
implementations  would  be  greatly  reduced.  Third,  an  operator  cannot  sense  whether  or 
not  it  will  receive  any  more  input.  In  particular,  monotonicity  does  not  allow  the 
specification  of  an  operator  which  produces  the  single  output  value  true  if  its  receives 
an  empty  input  history  and  false  otherwise. 1 

Continuity  implies  that  no  operator  can  produce  output  after  receiving  an 
infinite  amount  of  input.  An  operator's  response  to  an  infinite  input  history  must  be  the 


1.  This  is  quite  different  from  the  empty  stream  operator  of  Weng[19]  which 
produces  true  if  its  first  input  token  is  the  end  of  stream  token. 
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limit  of  its  responses  to  finite  prefixes  of  that  history. 

Now  we  shall  describe  the  derivation  of  the  history  function  characterization 
of  a data  flow  graph  from  the  history  functions  of  its  operators.  The  syntax  of  graph 
descriptions  used  in  Chapter  2 was  chosen  to  emphasize  that  each  graph  operator 
places  a relation  on  the  histories  of  the  graph  links  and  ports  to  which  it  is  connected. 
This  relation  is,  of  course,  the  operator's  history  function.  When  the  histories  of  the 
graph  input  ports  are  fixed  by  a graph  input  history  tuple,  the  operator  history 
functions  form  a set  of  simultaneous  equations  having  as  their  variables  the  labels  of 
the  links  and  output  ports  of  the  graph. 

The  result  of  executing  a graph  G with  input  history  tuple  X may  be  derived 
by  use  of  a history  function  FG  x constructed  by  combining  the  history  functions  of  G's 
operators. 

Definition-.  Given  a graph  G with  links  and  output  ports  labeled  by  elements  of  4 and 
with  an  input  history  tuple  X,  let  x be  the  history  function  from  to  l ^ with  the 
a'th  component  of  Ffi  X(Z)  determined  as  follows.  There  is,  within  G,  one  operator 
output  port  assigned  to  a.  The  a'th  component  of  F6X(Z)  is  the  history  of  that 
operator  output  port  when  the  operator  is  applied  to  the  input  history  tuple  consistent 
with  the  assignment  of  its  input  ports  to  graph  ports  and  links  and  with  the  assignment, 
by  history  tuples  X and  Z,  of  histories  to  graph  ports  and  links. 

Theorem-.  pg  x is  continuous. 

Proof:  Follows  from  the  continuity  of  the  history  functions  of  the  operators  of  G. 

The  result  of  executing  G with  input  history  tuple  X is  some  history  tuple  Z such  that 
Fg  x(Z)  = Z.  Only  these  tuples  are  consistent  with  the  operator  history  functions. 

Because  FG  x is  continuous,  Scott's  [16]  least  fixpoint  operator  Y may  be 
used  to  determine  the  least  fixpoint  of  the  equation  FG  X(Z)  = Z.  The  definition  of  Y 
follows: 
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Definition  and  Theorem-.  Given  a continuous  function  F mapping  a complete  partially 
ordered  set  with  least  element  1 into  itself,  the  least  solution  to  the  equation: 

F(x)  = x 

exists  and  is  denoted  Y (F).  Furthermore,  letting  Fn  denote  the  function  formed  by 
composing  F with  itself  n times: 

Y iF)  = U F'i  1) 

Proof  -.  To  prove  that  Y(F)  is  a fixed  point,  first  prove  that  F1  (1)  E F/+1(l).  To  prove 
that  Y(F)  is  the  least  fixed  point,  first  note  that  if  Fix)  = x then  F'(l)  E x Implies 
F'+1(i)  E Fix)  - x. 

Kahn  states  that  Y(FG  x)  is  the  history  tuple  of  the  links  and  output  ports  of  G resulting 
from  the  execution  of  G with  input  X.  Since  tA  represents  the  history  tuple  that  has 
"passed"  through  the  links  and  output  ports  at  the  beginning  of  execution  and  since 
the  passing  of  pQXiiA)  implies  the  eventual  passing  of  Fq+*(£*).  *he  choice  of 
u fg,x(?/,)'  or  Y(fg,x)-  as  the  result  seems  intuitively  correct. 

The  history  function,  OEgJ,  of  G is  defined  so  that  Ol[G]](X)  is  Y(F6X) 
restricted  to  the  labels  of  the  output  ports  of  G.  It  is  easily  shown  that  Off**])  Is  a 
continuous  history  function.  Furthermore,  0[[g]]  is  a complete  semantic  specification 
of  G in  the  sense  that,  if  H is  a graph  containing  an  operator  g with  the  same  history 
function  as  G,  the  graph  H[g/G ] obtained  from  H by  substituting  G for  each  occurrence 
of  G lias  the  same  history  function  as  H.  Consequently,  in  deriving  the  history  function 
of  a graph,  subgraphs  and  operators  may  be  treated  alike.  Subgraphs  do  not  have  to 
be  expanded  into  their  operator  implementations. 

In  the  last  section  of  this  chapter,  the  least  fixpoint  derivation  of  a data 
flow  graph  will  be  given.  Readers  desiring  more  complete  proofs  of  the  theorems 
stated  in  this  section  should  consult  the  work  of  Kahn  [12]  and  Scott  [16]. 


•3 
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3.2  The  Semantic  Specification  of  the  Data  Flow  Operator* 

All  ADFL  operators  and  constants  have  an  Interpretation.  The  interpretation, 
^|[oper]],  of  an  operator  oper  is  a function  from  Vm  to  V".  J/([oper]|  is  the  usual 
arithmetic  or  Boolean  function  associated  with  oper.  For  example: 

.P|[+]](*,  y)  = x + y 

JJ|[A])(x,  y)  = x A y 

J?[[oper])  is  assumed  to  map  "inappropriate"  Input  tuples,  such  as  those  containing 
values  of  an  unexpected  type,  Into  some  appropriate  tuple  of  output  values. 

The  history  function,  O\[oper]\,  of  the  data  flow  operator  oper  maps 
m-tuples  of  input  histories  into  n-tuples  of  output  histories.  The  data  flow  operator 
receives  a sequence  of  input  m-tuples  and  computes  the  sequence  of  n-tuples 
resulting  from  the  application  of  ^ffoper] J to  each  input  m-tuple.  Furthermore,  the 
firing  rule  of  the  data  flow  operator  is  strict.  The  operator  will  not  fire  without  a 
complete  tuple  of  inputs. 

0[[oper]](X)  = €*,  If  3 / 3 X;  = £ 

OC°Pef]l(*,X)  = J/[[oper])(x)*0[[°Per]l(X),  If  x € Vm 
Because  Offoper])  must  be  continuous,  it  suffices  to  define  O^oper^  only  on  finite 
input  history  tuples. 

The  interpretation,  .JJjconsf]),  of  a ADFL  constant  const  is  an  element  of  V. 
The  history  function,  Olcons/J,  of  the  data  flow  constant  operator  const  maps  Into 
V".  Data  flow  graphs  are  constructed  so  that  constant  operators  receive  only  trigger 
input  values.  An  output  of  value  ,^([const]l  Is  produced  for  every  trigger  Input 
received. 

Olcor>sf]l({)  r ( 

Offcor>sf]](trlgger*X)  = ^|[consfj'0|[c°'wf]l(',0 


r — r~ 1 
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Recall  the  firing  rules  of  the  data  flow  gate  operators.  The  gate  operators 

are  not  strict.  They  absorb  values  from  selected  input  ports.  The  history  function  of 

the  T gate,  respectively  F gate,  maps  into  V^.  When  a true,  respectively  false, 

control  value  is  received,  the  data  value  is  absorbed  and  passed  through  the  output 

port.  When  any  other  control  value  is  received,  the  data  value  is  absorbed  and  no 

output  is  produced. 

OE T gate]](f.  Y)  = € 

0|[T  gate])(x*X,  f)  = € 

OlT  gate]](true*X,  yY)  = yOET  gate]](X,  Y) 

OEt  gate]]U*X,  yY)  = 0ET  gate]](X,  V),  if  x * true 

0|[F  gatejKf,  V)  = C 
0EF  gate]]U*X.  f)  = i 

OEF  gate]](false-X,  yV)  = yO[T  gate]](X,  y) 

OlF  gate]](yX,  yY)  = OE T gate]](X,  Y),  if  x * false 

The  history  function  OEM  gate]]  maps  into  V^.  The  control  value 

selects  which  data  value  is  passed  to  the  output  port.  If  a non-Boolean  control  value 

is  received,  no  data  value  is  absorbed  and  err  is  output.  The  FM  gate  is  a M gate  with 

a built-in  initial  false  control  value. 

OEM  gatejff,  Y,  Z)  = i 
OEM  gate]](true*X,  (,  Z)  = t 

OEM  gate]](true-x,  yY,  Z)  = yOEM  gate]](X,  /,  Z) 

OEM  gate]](false-X,  V,  f)  = £ 

OEM  gate]](f  alse*X,  y,  Z’Z)  - z*OEM  gate]](X,  Y,  Z) 

OEM  gate]](*-X,  Y,  Z)  = err*OEM  gate]](X,  y,  Z),  if  x * {true,  false) 

OEFM  gate]](X,  y,  f)  = ( 

OEFM  gateJfX,  Y,  z-Z)  = z*0 E™  gate]J(X,  y,  Z) 

The  history  function  OE^S  gate]]  maps  into  V^.  When  a false  control 


value  is  received,  the  FS  gate  passes  its  data  value  and  sets  an  internal  register  to 
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that  value.  When  a true  control  value  is  received,  the  FS  gate  absorbs  no  data  value 

but  outputs  the  value  contained  in  its  register.  The  FS  gate  has  an  initial  built-in  false 

control  value.  The  control  value  of  the  FS  gate  is  the  iter?  value  of  an  iteration  body 

and,  consequently,  must  be  either  true  or  false. 

0([FS  gate]l(X,  O = £ 

OllFS  gate]l(X,  y-V)  = y-Sy(X,  Y) 

S2<£,  Y)  = £ 

Sz(true-X,  V)  = Z'S^X,  Y) 

S2(false*X,  £)  = £ 

Sr( false-X,  y-V)  = y*Sy(X,  Y) 

Compare  the  history  function  specification  of  the  1C  gate  with  the  table 

specification  of  its  firing  rules  given  on  page  23. 

OElC  gate]J(€,  Y,  Z)  = (£,  £,  £) 

OfflC  gate]](true-X,  £,  Z)  - (£,  £,  £) 

Ol[lC  gate]j(true-X,  true*/,  Z)  = (true,  true,  €)*Off,c  gate]J(X,  Y,  Z) 

0[[lC  gate]](true*X,  falsely,  Z)  = (false,  £,  trueVOfflC  gate]J(X,  V,  Z) 

OfflC  gate])(false*X,  /,  £)  = ((,  £,  £) 

OfflC  gatej(f alse*X,  Y,  tru e*Z)  = (true,  false,  O'OfflC  gate|(X,  Y,  Z) 

Off  1C  gate]](false*X,  Y,  false*Z)  = (false,  (,  false)*OfflC  gate]l(X,  Y,  Z) 

C)K IC  gateJ(jfX,  V,  Z)  = (false,  £,  err)*OfflC  gate]l(X,  Y,  Z),  if  x £ {true,  false) 

The  E gate,  the  only  remaining  gate,  passes  its  data  value  when  It  receives 
a Boolean  -ontrol  value,  and  absorbs  no  data  value  and  produces  err  when  it  receives 
a non-Boolean  control  value. 

OK*  gate]](£,  y)  = £ 

OffE  gate]](x*X,  £)  = £,  if  x e {true,  false) 

Off E gate]](x*X,  yY)  - yOffE  gateJ(X,  Y),  if  x e {true,  false) 

OffE  gate]](x*X,  y)  = OffE  gate]](X,  Y),  if  x t {true,  false) 

The  history  function  specifications  of  the  data  flow  operators  of  Chapter  2 
completed,  the  operational  semantics  0°T)KexP&  of  an  ADFL  expression  exp  may  be 
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obtained  by  using  the  translation  algorithm  to  construct  the  data  flow  graph 

and  using  the  operator  history  function  specifications  and  Kahn’s  fixpoint  theory  to 

derive  0°.7[[e*pli.  This  method  of  deriving  operational  semantics  is  illustrated  in  the 
following  section. 

3.3  Operational  Semantics  for  an  ADFL  Expression 

In  this  section  the  operational  semantics  of  the  iteration  expression 

"let  idn  = exP  in  aeration"  Is  derived  assuming  the  operational  characteristics 

of  its  component  initialization  expression  and  iteration  body.  For  convenience,  let  G, 

Gmit,  and  Giter,  denote  the  data  flow  graphs  of,  respectively,  the  iteration  expression, 

the  initialization  expression,  and  the  iteration  body.  Recall  from  Chapter  2 the 

operators  list  of  the  graph  description  of  G. 

Ginit  inputs:  (a  e Ginit ) a -*  a 
outputs:  (/  e 1 ..  n)  i -»  a, 

(/  e1..n)  FM  gate  inputs:  7||w?  -♦  1, 7,  -♦  2,  a,  -»  3 
outputs:  1 -♦  /3W/ 

(a  e IN(G/fer)  - {id  1,  ....  idn})  FS  gate  inputs:  7|(er,  ->  1,  a -♦  2 

outputs:  1 -» /9a 

Giter  inputs:  (a  e IN(G/fer))  0 a -♦  a 

outputs:  iter?  - 7„er?,  (/el.,  n)  1/  - T/t  (R/  € ROUT(G/ter))  R/  i 

We  assume  the  history  functions  Q^GinitJ  and  OllG/fer])  have  been  derived, 
recursively,  using  fixpoint  theory. 

OflGjU)  is  found  by  deriving  the  least  fixed  point  of  FGX.  In  Section  3.1, 
Fa,x  was  (lo,inc(l  as  a history  function  from  l/0^  to  V01*  where  A contains  the  labels  of 
the  links  and  output  ports  of  G.  From  the  graph  description  we  see  that  A contains: 

(/  e 1 ..  n)  ar  (a  e IN(Grfer))  0a,  \et?,  (/el.,  n)  7(,  (R  / e ROUT(Gfter))  < 

A 

Given  Z of  l/^  , let  ZG((er  denote,  in  a slight  abuse  of  notation,  the  tuple  mapping 


— 


I U(Giter)  into  V,  and  let  XG|n|(  denote  the  tuple  mapping  IN(G/n/()  Into  V,  such  that: 

w>  • ««.) 

XG»II(*>  * X<*> 

^Gner  is  c,ef‘net*  *°  reflect  the  assignment  of  Input  port  a of  Giter  to  link  /9J  of  G;  and 

*Gln„.  the  assignment  of  input  port  a of  Ginit  to  input  port  a of  G.  F GX(Z)  is  the 

element  of  l/***  such  that: 

FG,x*z^a/)  = 0l[G/'n/f3(XGlnlt)(/),  if  / e 1 ..  n 

FG  X(Z)(/3W)  = C)l FM  gatej(Z(7|(er7),  Z<7,),  Z(.a,)),  if  / € 1 ..  n 

FG,x<z>^a^  = Off FS  gate3(Z(7|tef7),  X(a)>,  it  a e IN(G/ter)  - {/dl Idn > 

FG,x<z><Vf>>  = 0l[G/fer3(ZG(ter)(iter?) 

fg  x(Z)(7,)  = OffG/fer 3(ZQlter)(l/),  if  / e 1 ..  n 

F G X(Z)(/)  = 0[[G»fer3(ZG|)er)(R/),  if  R / e ROUT(GZter) 

Suppose  all  input  history  components  of  X contain  a single  value.  That  Is, 
suppose  X represents  a single  set  of  input  values  to  G.  Further  suppose  that  G,  given 
input  X,  iterates  m+1  times  before  producing  its  output  tuple.  Let  l/Q  be  the  r?-tuple 
produced  by  the  initialization  expression  subgraph,  Ginit,  and  initially  bound  to  the 

iteration  variables,  id  1 idn.  Let  I/,,  ...,  l/m  be  the  n-tuples  produced  by  the  first  m 

iterations  of  the  iteration  subgraph,  Giter,  and  let  W be  the  ultimate,  non-iter,  output 
tuple  produced  on  the  final  iteration.  The  formal  relation  between  these  tuples  and  the 
history  functions  OffG/n/fJ  and  OffG/terJ  follows. 

Since  l/Q  is  produced  by  Ginit 
l/0  = OffG/n/t]l(XGW,) 

On  the  yth  iteration,  the  input  tuple  1/^.,  is  received  at  input  ports  of  Giter  labeled  by 
the  iteration  variables.  Other  input  ports  receive  values  contained  in  the  graph  input 
tuple,  X.  Let  l/X,  , represent  this  input  tuple. 
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l/X;_ ,(/<//)  = l/y.,(/),  if  / e 1 ..  n 

l/Xy1(a)  = X(a),  if  a e IN(G/fer)  - {/of  1 Idn) 

At  the  end  of  the  y'tli  iteration  of  Giter,  for  j not  greater  than  m\  the  tuple  l/y  Is 

produced  on  the  I output  ports  of  Giter : true,  on  the  iter?  output  port;  and  no  values, 

on  the  R output  ports.  Consequently: 

O[[G/fer]](l/X0*...*l/Xy.1)(iter?)  = true' 

OffG/fer]](l/X0....-t/Xj.,)(lr)  = l/0(/)-...-l/y(/),  if  i e 1 ..  n 
OttG»fer]](l/X0*...-l/Xy.,)(R/)  = t,  if  R/  e ROUT(G/fer) 

Where  true'  is  the  sequence  of  j true  values.  At  the  end  of  the  last,  m+1'st,  Iteration 

of  Giter ; the  tuple  IV  is  produced  on  the  R output  ports  of  Giter-,  false,  on  the  iter? 

output  port;  and  no  values,  on  the  I output  ports.  Consequently: 

0([G/fer]I(l/X0-...-l/Xm)(iter?)  = truem-false 
O[[G/tcr]](l/X0-...«l/Xm)(l/)  = l/0(/>...*l /JO,  if  / e 1 ..  n 
O^Giter J(l/X0*...*l/Xm)(R/)  = IV(/),  if  R/  e ROUT(Gfter) 

Using  this  history  function  specification  of  Giter  and  Ginit,  the  reader  may 

verify  that  for  the  least  fixed  point  Y(FG  x),  or  U ^(E*),  of  FQ  x is  the  tuple  mapping 

A,  the  labels  of  the  links  and  output  ports  of  G,  into  1/  such  that: 

Y(F = I /0(f).  if  i e 1 ..  n 

= ^Jib.^VJI),  if  ' € 1 ..  n 

Y(FG,x)(^a)  = if  a e IN(G/(er)  - {id  1 idn } 

Y(FG  x)0'„er?)  = truem*f  alse 
Y(F6>7,)  = l/,(/)-...-l/m(/),  if  / e 1 ..  n 
Y(FG  X)(i)  = W(i),  if  R i e ROUT(G/<er) 

Consequently,  OffG]](X)  is  IV,  Y(FGX)  restricted  to  the  output  port  labels  of  G.  As 
expected,  IV  is  the  output  tuple  produced  by  the  final  iteration.  Note  that  false  was 
produced  as  the  iter?  value  on  the  final  iteration,  thus  resetting  the  FM  gate  and 
FS  gate's  for  a new  set  of  inputs.  This  example  derivation  demonstrates  how  the  data 
flow  graph  implementation  of  the  iteration  expression  satisfies  its  intended  function. 
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The  operational  semantics  of  any  ADFL  expression  may  be  derived  similarly. 
First,  the  expression  is  translated  into  a data  flow  graph.  The  operational  semantics  of 
the  expression  is  the  history  function  of  its  graph.  The  history  function  of  the  graph  Is 
obtained  by  recursively  using  Kahn's  theory  to  obtain  the  history  functions  of  the 
subgraphs  corresponding  to  the  syntactic  components  of  the  expression.  The  basis  of 
the  recursion  is  the  history  function  characterizations  of  the  elementary  data  flow 


operators. 


4.  Conclusions  and  Suggestions  for  Future  Research 


The  operational  semantics  of  ADFL,  an  applicative  data  flow  language  with 
an  iteration  construct  resembling  tail  recursion,  have  been  expressed  as  a two  step 
process.  In  the  first  step,  the  application  of  the  translation  algorithm  to  an  ADFL 
expression  yields  its  data  flow  graph  implementation.  In  the  second  step,  the 
application  of  the  semantic  function  ()  to  the  graph  yields  its  semantic 
characterization.  The  graph  is  an  explicit  representation  of  the  concurrency  possible 
in  evaluation  of  the  expression.  It  is  an  interconnection  of  data  flow  operators, 
corresponding  to  ADFL  operators,  which  communicate  values  to  each  other  through 
input  and  output  ports.  In  conventional  sequential  control  flow  evaluation,  operators 
ore  performed  in  a pre-ordained  sequential  order.  In  data  flow  evaluation,  operators 
are  performed  as  soon  as  their  arguments  are  available. 

The  translation  algorithm  fj  is  recursive.  The  graph  of  an  expression  is 
constructed  from  subgraphs  implementing  its  syntactic  subcomponents.  The  graph  has 
an  input  port  for  each  free  variable  of  the  expression  and  an  output  port  for  each 
value  returned  by  the  expression.  Data  flow  graphs  are  specified  with  a graph 
assembly  language  well-suited  for  describing  fj. 

When  expressions  ore  evaluated  under  sequential  control  flow,  execution 
exceptions  ore  often  handled  by  interrupts.  However,  in  ADFL  an  error-handling 
scheme  more  appropriate  to  both  the  concurrency  of  data  flow  and  the 
value-orientation  of  the  language  is  used.  Special  error  values  are  returned  when 
exceptions  occur.  Conditional  and  iteration  expressions  are  implemented  with  special 
gates  designed  to  be  consistent  with  this  error-handling  philosophy. 
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In  the  second  step  in  obtaining  the  operational  semantics  of  an  ADFL 
expression,  the  application  of  the  semantic  function  f)  to  the  graph  of  the  expression 
yields  its  semantic  characterization.  The  result  of  executing  a graph  is  characterized 
by  a history  function  mapping  a tuple  of  input  histories  into  a unique  tuple  of  output 
histories.  The  history  function  of  a graph  is  derived  by  use  of  Kahn's  fixpoint  theory  of 
communicating  interconnecting  processes.  Here,  the  processes  are  the  data  flow 
operators.  Thus,  the  operational  semantics  of  an  AOFL  expression  is  obtained  by 
application  of  0°_ /•  C)°T)  maps  an  ADFL  expression  through  its  data  flow  graph 
implementation  to  its  history  function  characterization. 

There  are  three  avenues  for  extending  this  research.  First,  the  language 
may  be  extended.  Second,  the  operational  characterization  of  data  flow  graphs  may 
be  modified  to  more  closely  correspond  to  execution  on  specific  data  flow  machines. 
And  third,  an  alternative  semantic  characterization  of  data  flow  languages  may  be 
given  and  proven  consistent  with  this  operational  characterization. 

The  most  obvious  language  extension  is  the  addition  of  procedures. 
Procedures  may  be  implemented  at  the  data  flow  graph  level  with  an  apply  operation 
which  receives  a data  flow  graph  on  one  input  port  and  values  to  which  the  graph  is  to 
be  applied  on  its  remaining  input  ports.  Since  Kahn's  theory  can  be  extended  to 
include  recursive  graphs,  it  is  easy  to  characterize  the  operational  semantics  of  such  a 
data  flow  language. 

Another  language  extension  is  the  incorporation  of  the  determinate  stream 
operators  of  Weng  [19].  A stream  is  a list  whose  elements  are  generated  over  time. 
Stream  operators  process  these  lists  one  element  at  a time.  Consequently,  the 
concurrency  of  data  flow  program  execution  is  increased  by  allowing  a data  flow 
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operator  to  process  elements  of  an  input  stream  value  while  elements  of  an  output 
stream  value  are  being  generated.  Determinate  stream  operators  are  naturally 
characterized  by  history  functions,  and,  thus,  Kahn's  fixpoint  theory  may  be  used  to 
define  the  operational  semantics  of  a language  with  determinate  stream  operators. 

A non-determinate  stream  operator,  merge,  has  been  used  by  Arvlnd, 
Gostelow,  and  Plouffe  [4]  and  Dennis  [8]  in  data  flow  Implementations  of  real-time 
systems,  such  as  resource  allocators  and  airline  reservation  systems.  The  merge 
operator  accepts  two  input  streams  and  merges  them  into  one  output  stream.  The 
output  stream  may  be  one  of  several  interleavings  of  the  input  streams.  It  Is  difficult 
to  extend  Kahn’s  fixpoint  theory  to  non-determinate  computation.  Brock  and 
Ackerman  [6]  have  shown  that  arbitrary  non-determinate  data  flow  graphs  cannot  be 
operationally  characterized  by  the  natural  extension  of  history  functions,  a mapping 
from  tuples  of  input  histories  to  sets  of  tuples  of  output  histories,  while  Kosinskl  [13] 
has  described  an  operational  semantics  of  non-determinate  data  flow  graphs  In  which 
each  data  flow  value  is  "tagged"  with  the  non-determinate  "choices"  leading  to  its 
generation.  Kosinskl's  theory  seems  unnecessarily  complicated  since  non-determinate 
computations  may  be  simulated  without  tagging  values.  Consequently,  a simpler 
characterization  of  non-determinate  data  flow  computation  may  exist.  An  alternative 
area  of  research  is  finding  a non-determinate  data  flow  language  which  restricts  the 
use  of  merge  operators  so  that  graphs  have  a simple  operational  characterization. 

The  second  avenue  of  extending  this  research  is  the  operational 
characterization  of  data  flow  computation  on  specific  machines.  Kahn's  theory 
assumes  that  the  links  of  data  flow  graphs  are  unbounded  FIFO  queues;  however,  In 
the  data  flow  machine  design  of  Dennis  and  Misunas  [9],  the  links  are  one-place 


buffers.  If  operators  are  allowed  to  "write  over"  buffered  values,  graph  computation  Is 
non-determinate.  Presently,  Montz[14]  is  investigating  the  use  of  acknowledge 
signals  to  control  operator  firings.  In  this  scheme,  whenever  an  output  and  input 
operator  are  connected  by  a link;  a second  acknowledge  link  is  placed,  In  the  opposite 
direction,  between  the  operators.  The  output  operator  will  not  place  a value  on  the 
data  link  until  it  has  received  an  acknowledge  value,  and  the  input  operator  generates 
an  acknowledge  value  whenever  it  removes  a data  value.  Semantically,  graphs 
constructed  with  this  acknowledge  protocol  may  be  considered  to  contain  links 
implemented  by  unbounded  FIFO  queues;  although,  in  actual  execution,  only  one  place 
of  the  queues  will  ever  be  used. 

The  third  avenue  is  proving  that  the  operational  semantics  of  ADFL  are 
consistent  with  a more  abstract  semantic  characterization.  The  denotational 
semantics  [18]  of  a language  are  given  by  defining  a direct  mapping  of  syntactic 
components  to  suitable  abstract  objects.  For  example,  procedures  may  be  mapped 
into  functions  without  regard  to  details  of  implementation  or  execution.  Scott's  [16] 
theory  provides  the  theoretical  basis  for  defining  iterative  computation  and  for 
constructing  abstract  objects  for  syntatic  components.  Since  ADFL  Is  applicative,  the 
sole  effect  of  evaluation  is  to  return  a tuple  of  values  dependent  solely  on  the  values 
bound  to  the  free  identifiers  of  the  evaluated  expression.  Consequently,  any 
expression  of  ADFL  may  be  denotationally  characterized  by  a function  mapping  each 
environment,  association  of  identifiers  and  values,  into  the  tuple  of  values  returned 
when  the  expression  is  evaluated  within  that  environment.  The  denotational  semantics 
of  ADFL  have  a simple,  elegant  statement.  Further  research  of  this  author  will  prove 
that  the  operational  and  denotational  semantics  of  ADFL  are  consistent. 
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